Related - #53091. @javiercn, is the commented-out portion of the target going to be used anywhere other than in publishing.props? If so we should separate that out into a separate target & name it something else.

I was keeping the structure as close as possible to what was there. I don't feel strongly about it either way.

The previous code was grabbing the version from the functional test project directly, which was a bit random.

I don't know exactly what the version info is being used for, so I just made sure we captured all the versions. In reality we version all the packages simultaneously.

In my view, if we are generating some sort of manifest, we should include the versions for all packages that we ship, just in case we break something and produce the wrong version.

I don't know exactly what the version info is being used for, so I just made sure we captured all the versions. In reality we version all the packages simultaneously.

In my view, if we are generating some sort of manifest, we should include the versions for all packages that we ship, just in case we break something and produce the wrong version.

The comment below isn't entirely accurate:

https://github.com/dotnet/aspnetcore/blame/1c6c34733003e5236315b959d1729be2bf14968d/eng/Publishing.props#L57-L60

The target in which we call _GetPackageVersionInfo will return the PackageVersion only for the project on which we called it - then we use that package version to construct a path for publish files to be dropped in to. We chose an arbitrary nonshipping package for that, because we need a unique path per-build. We can't just use the PackageVersion property directly in publishing.props, because it hasn't been set yet by the time we get there, so we have to do it in a target. Historically the arbitrary nonshipping package we chose was an npmproj - I don't think there's any strong reason to keep trying to use the new nodeproj, hence why I suggested dotnet-user-jwts. Now that I think about it though, I think Microsoft.Aspnetcore.Testing makes more sense. I'm going to update this PR now & try a test internal build.

The comment below isn't entirely accurate:

https://github.com/dotnet/aspnetcore/blame/1c6c34733003e5236315b959d1729be2bf14968d/eng/Publishing.props#L57-L60

The target in which we call _GetPackageVersionInfo will return the PackageVersion only for the project on which we called it - then we use that package version to construct a path for publish files to be dropped in to. We chose an arbitrary nonshipping package for that, because we need a unique path per-build. We can't just use the PackageVersion property directly in publishing.props, because it hasn't been set yet by the time we get there, so we have to do it in a target. Historically the arbitrary nonshipping package we chose was an npmproj - I don't think there's any strong reason to keep trying to use the new nodeproj, hence why I suggested dotnet-user-jwts. Now that I think about it though, I think Microsoft.Aspnetcore.Testing makes more sense. I'm going to update this PR now & try a test internal build.

Seems that we can rip the entire thing in that case.

Test build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2345984&view=results

Seems that we can rip the entire thing in that case.

Agreed - #53153